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Abstract 

Many computer-based authentication schemata are based on pass- 
words. Logging on a computer, reading email, accessing content on a 
web server are all examples of applications where the identification 
of the user is usually accomplished matching the data provided by 
the user with data known by the application. 

Such a widespread approach relies on some assumptions, whose 
satisfaction is of foremost importance to guarantee the robustness of 
the solution. Some of these assumptions, like having a "secure" chan- 
nel to transmit data, or having sound algorithms to check the correct- 
ness of the data, are not addressed by this paper. We will focus on 
two simple issues: the problem of using adequate passwords and the 
problem of managing passwords. 

The proposed solution, the pathword, is a method that guarantees: 

• that the passwords generated with the help of a pathword are 
adequate (i.e. that they are not easy to guess), 

• that managing pathwords is more user friendly than managing 
passwords and that pathwords are less amenable to problems 
typical of passwords. 
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1 Passwords: they are useful only if they 
are robust 



Assume to have a service S which must be accessed only by trusted 
users. The authentication of a user U is accomplished by having U to 
provide for an identity (usually a user name u) and for a secret password 
p. The secret must be known only to U , to S and to no other and it 
must match the secret that the service already know. 

This schema allows S to check that a user U' , faking for U , is not 
the intended user, since U' , by definition, is not able to provide to S 
the p that is linked to u. As usual, we assume that the identities are 
publicly known, or that an attacker can easily discover them, and that 
all that must be kept secret are indeed the passwords. 

Since p is known only to U , this system is robust only if the fol- 
lowing assumptions hold: 

1. pis not "easy" to guess — we will make clear the exact formal 
meaning of "easy" in a moment, 

2. U has a simple and friendly way of managing its own many p, 
corresponding to its many identities in its many services, oth- 
erwise U can be tempted to write them down somewhere, or to 
use "simple" p that are amenable of being stolen or guessed. 

Of course, the above list is not complete, since in a real-world case 
there can be many other issues to be considered, depending on the 
technology, on the relevance of the accessed services or on the partic- 
ular characteristics of the interaction between U and S. 

From now on, when we talk about services, we assume them to 
be like those mentioned in the introduction (terminal login, access to 
email or to web-based applications, and so on), where an actor has to 
provide its own data to a computer program, through a keyboard 
or any other similar device: this range of services, far from being 
complete, is of great relevance to the daily practices of many Inter- 
net users. 

1.1 Easy passwords are an hard problem 

What is an "easy" password in the sense of item^above ? It is a secret 
that is not so difficult to discover. 
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Assume, without loss of generality, that p is simply a word in the 
full language A* of an alphabet A. If we know that p is of length 
n, then there are |^|" possible guesses for p. This means, that, if p is 
randomly chosen, and there are no biases, the probability of guessing 
it is only |^|^" and that there need approximately |^|"/2 attempts to 
guess it. We associate to each service S a timeframe Ts that measures 
how long it takes, on average, to guess one p for S, and we say that 
that p is adequate for S when the estimated time to guess is greater 
that Ts- Ap which is not adequate, is easy. 

Of course, in a perfect world, Ts would be infinite, but this re- 
quirement is clearly impossible. For example, if we take A as the bi- 
nary alphabet {0, 1}, as one year, and we assume that an attacker 
can check by brute force 10^ passwords each second, we have that an 
adequate p must be strictly more that 46 bits long since: 

2"^^ > 10^(pwd/sec)*3600(sec/hour)*24(hour/day)*365(day/year) 

If we assume that the attacker gets stronger or weaker computa- 
tional power, the estimate changes consequently. 

Forty-six bits of password are not too many: they are guaranteed 
by a 7 letter random string chosen from the ASCII alphabet (which 
has 2^ characters in it). In practice, we already face a problem, since 
a randomly chosen word in ASCII^ can be very hard to remember 
and technically very hard to type on an ordinary keyboard, due to 
the presence of codes that are interpreted as control characters. If we 
stick to a more ordinary alphabet of 16 letters, like the hexadecimal 
code, we need a twelve letter password (which really is 48 bits long): 
it surely is simpler to write (since we have only ten digits and the 
letters A, B, C, D, E and F) but it can be even harder to remember. 
Please try to remember this string, you will be asked about it later: 

AC43 A172 EICB 879D 

Remembering many different passwords is a heavy burden, recog- 
nised by many researchers. Many security practices (see CI and |3|, 
for example) warn against writing down complex or long passwords, 
since this helps potential attackers. On the other side, the same prac- 
tices advise against using common words or strings that have a mean- 
ing since this makes the passwords amenable to dictionary attacks. In 
both cases it is entirely a user problem to manage their (many) pass- 
words in order to fulfil security requirements and to be able to use 
the same passwords efficiently. In is reported in [2J (pages 104 - 105) 
that "... entropy (...) of standard English at less than 1.3 bits per char- 
acters; passwords have less than 4 bits of entropy per character", as 
opposed to the theoretical 8 bits of entropy of an ASCII character. 
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2 A simple solution: write them down 

Some solutions to the above conundrum have been proposed, like 
having external tokens or devices that provide the secret that uniquely 
identifies the user, or using helper programs that store securely the 
passwords. 

In the following we will propose an alternate schema, called path- 
ivords, which we believe is: 

• secure {i.e. it allows the management of adequate passwords), 

• user friendly (i.e. it is easy to devise helper applications, to re- 
member and use passwords, and so on). 

The following example explains the idea behind the pathivord ap- 
proach. 
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Figure 1: First example 



How easier is an attacker job if we state that our own secret pass- 
word is stored in the diagram of picture^? By "stored" we mean that 
we are able to read it out from the picture, with no other help. 

Quick, now: which was the secret hexadecimal word of the pre- 
vious section ? Have you been able to remember it correctly ? If the 
answer is yes, congratulations for your memory, otherwise the fol- 
lowing hint may be useful. 
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Figure 2: Annotated example 
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Figure 3: Path example 



The numbers appearing at the exponent of some letters indicate 
the order to follow to read out the secret word: first the letter a, then 
c, and so on, ending with 9 and d. Another picture shows even more 
clearly the pattern followed to read out the password. 

It is our position that remembering patterns (or paths) like those 
depicted in picture|3lis easier than remembering passwords, that this 
practice leads people to use stronger passwords and that no security 
is lost in the process. By "security", here, we mean that the practice of 
remembering passwords with the help of patterns like those sketched 
above does not help an attacker significantly. 



3 Analysing pathwords 

Informally, a pathword vr is any walk on the cells of a table like that 
previously depicted. Formally, a pathword vr is a function between 
elements of some space S (in the previous example, S is the space 
of 6x6 matrices over the hexadecimal code alphabet) to the strings 
over another alphabet. For the sake of simplicity, and with no loss of 
generality, we assume that the two alphabets are always the same. It 
is easier to represent pathwords with diagrams like those of figure 
|3l but any other representation is obviously equivalent. For example, 
the transformation given by figure IH is 



7r({aij|l <i,j< 6}) = ai^iai^2ai,6ai,5a2,i ■ ■ ■ a5,5a6,i«6,206,6a6,5 

Some key points to be considered are the following: 

• users should have more than one pathword, perhaps a least 
three or four, perhaps clustered around different security con- 
cerns (for example, an "easy" pathword like the one above to 
read out password to access less important services, another 
one for more important services and a more complex one to 
read out password of really sensitive services). 
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• the diagrams themselves can even be pubUc, since they convey 
no useful information to potential attackers (see about this in 
section l3.lt , 

• users should not try to make their passwords easier to remem- 
ber or to build them following rules: in fact doing this will lower 
the effective complexity of the password, making it easier to 
guess. 

The key question to be answered is: "Assuming the adoption of 
a pathword, does this undermine the security of the identification 
process ? If not, under which further assumptions ?" The remaining 
of the paper is devoted to examining this question. 

3.1 Robustness of pathwords vs passwords 

Let's define as d any diagram (for example a table) on an alphabet A. 
Then a pathword is a function vr : d — > p which maps dto apm A*. 
Given a length n, the probability of guessing a random string in A" 
is 1^1 ~" . If d contains only a subset A' of letters, and vr does not have 
repetitions {i.e. it never passes twice on any cell), then the number of 
possible sequences is lower-boimded by 

n 

ll{\A'\-ij-l)) 

Since we have no constrains on d, other than the usability of the 
proposed solution, we can declare that the process of generating d is 
not completely random, and that A' = A. The ratio r between the 
number of sequences obtained by vr and the number of sequences of 
a perfectly random process is 

II j=i I I II 

if we set k = \A\/{n — 1) then we have 
^ > (1 _ 

k 

a \A\ » n, \A\ is big and n is small, also k is big (since it is 
approximatively a rfi^ fraction of A) and (1 — 1/A;)'^ is approximable 

by e~^, so 

1 
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but \A\/k'^ = {n — l)/k << 1. This means that r is not far from 1 
(in the worst case, if A is comparable with fc^, r is still bigger that 
or approximately 37%). 

Theorem 1 Assume that A is large and n is small, as in the above analysis. 
Given a password p G A"', and given a diagram d where all the letters in 
A appear, it is possible to have a ^{d) of the same strength of p just taking 

TT{d) E 

Proof: Since in the worst case the ratio between the number of avail- 
able sequences and the full set is only of e^^, this means that the gain 
of a possible intruder is less than e times. Choosing a longer word, of 
just two more bits, enlarges the password space by four times, negat- 
ing the above speedup. Since A is large, by definition, it is enough to 
add one single letter. □ 

By theorem^ using pathwords does not imply to have longer 
passwords, in the worst case, just one character longer. 



3.2 An interface to a pathword system 

It is not clear yet which is the better trade-off between the size of 
the alphabet A, the size of passwords p and the best way to deploy 
diagrams d. 

Assume that d is a square matrix of 100 elements and that the 
alphabet is composed of all the couples of digits {i.e. the alphabet of 
the 100 "letters" ranging from 00, 01, . . . to . . . 98, 99). 

Notice that to have a 64 bits password p, p must be at least ten 
characters long. A pathword of length ten is not too complex to re- 
member and can be even something with very few structure in it, and 
yet short enough to be remembered. Just to make a comparison, the 
pathword of picture [S] is structured, the one HJ is less, the one [S] has 
been randomly generated. 
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Figure 4: "Triangle-shaped"path 
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Figure 5: Random path 



In the above example we have by explicit calculation that r 
63%. This means that it can be a realistic scenario. Notice that a 10 x 
10 square table is not very big: it can be easily shown on a web page, 
even on a PDA or printed on a sheet of paper of the size of a credit 
card. 

4 Discussion 

The following are some question that naturally arise. 

What happens if a user loses a pathword? And if it stolen? 

If a user has just one single pathword, and if it is stolen or lost, this 
can be a big problem, since an attacker will be able to access all the 
users'passwords, just by reading them from the diagrams. If a user 
had many pathwords, the loss is mitigated by the reduced number of 
accessible passwords. 

Comparing the loss of a password to the loss of a pathword, losing 
the pathword is potentially worse, since it subsumes the simultane- 
ous loss of many passwords. 

Why should be easier to remember a pathword instead of a password? 

It should be easier for two reasons: 

1. a user should have few pathwords, instead of passwords by the 
dozen, 

2. humans are better suited to remember visual patterns than ran- 
dom {i.e. structure-less) strings. 

Is it not enough to keep passwords in a secure device — like a PDA with 
some application — in some encrypted form? 

Maybe. But notice that if a secure solution is available to manage 
passwords, there should be no reason, in principle, for not using it 
also to manage pathwords. 

Having pathwords, instead of passwords, exposes the user to no 
further risk, if the application is secure. 
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Are passwords really not secure, in practice? 

We are not aware of definitive conclusions on this issue, but some 
previous works point out that: 

• real passwords are not truly random and are exploitable with 

brute force attacks, 

• people reuse the same passwords, sometimes even for services 
of different importance (for example, exposing the risk to have 
their electronic bank account accessed with the same credentials 
used to post on a public web forum devoted to their hobbies), 

• if people are forced to use really strong passwords, or to change 
them frequently, they tend to write them down somewhere, de- 
vising their own tricks to camouflage them, 

• changing passwords is an issue: people tend to reuse two pass- 
words, switching between them {i.e. having a summer pass- 
word and a winter password), or to generate a new password 
appending or changing some character to their previous pass- 
word {i.e. passwordA, passwordB, and so on). Technical solu- 
tions avoid these behaviours, but empirical evidence shows that 
changing passwords frequently really annoys users. 

Notice how pathwords address the above issues: 

• passwords read from pathwords tend to be adequate, 

• passwords are never reused: in fact, since a diagram can be gen- 
erated by the service to be accessed, there is a practical guaran- 
tee that no two diagrams are equal, 

• the number of pieces of information that has to kept secret is 
low, and so there is less pressure to devise ways of remembering 
them, 

• changing passwords can be an issue no more: a service can even 
change the password each time it is accessed, just by providing 
the user with a different diagram each time. 
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